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INTRODUCTION 



This paper is intended to provide the instructional 
technologist already possessing some understanding of expert 
systems with some insight into two of the many steps involved in 
the design and production of such systems; KNOWLEDGE ACQUISITION 
and KNOWLEDGE STRUCTURING (also known as KNOWLEDGE 
REPRESENTATION). It is also intended to help technologists to 
see how they might fit themselves into the knovjledge engineering 
(expert systems building) paradigm. 



We will begin by examining a generalized model tor the 
design and production of an expert system. We will then look m 
more detail at the first two steps in this model, knowledge 
acquisition and knowledge representation (structuring). The 
relationship between the instructional development process ano 
the knowledge engineering process will be emphasized. Finally, 
characteristics of the ideal knowledge acquisition engineer will 
be compared to those of the ideal instructional developer. We 
will show that the two processes are very similar, and that a 
cross-fertilization of both ideas, techniques and people btM.weei 
the two fields will prove both possible and profitable. 



THE MODEL 



The expert systems design and production model ot xuceresu 
to us is shown in Figure 1 (adapted from Martin and Oxman, 1988), 
As this figure shows, the first task involved in designing ari 
expert system is to select an appropriate problem to solve. This 
is possibly the hardest of his tasks for the knowledge engineer 
to accomplish properly . A great many of the jobs we perform 
every day as instructional technologists ate currently unsuil.c?nit 
for expert system development. For example, any task which i£i 
based upon hard-to-def ine knowledge, common serise, or in^uj: nn 
is unsuitable. So is any task in which it is unclear whetirif^r. 
when completed, the potential user would ever in fact use ihv. 
expert system. Many other characteristics must be met by the 
ideal task if it is to be suitable (cf., Martin and Oxman, 
1988, p. 130). 
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Once a problem has been selected, the next step is to 
obtain the data-base or set of knowledge that is the property or 
an expert working with this problem. There are several aspects 
to this step, and these will be discussed later in the paper. It 
is sufficient here to note that this step is probably the most 
time consuming and expensive step in the design and production 
process. It involves locating a suitable expert (called 
subject-matter expert, or SME, in instructio al development, and 
a domain expert in knowledge engineering), eliciting Iroin the 
expert the required knowledge, understandings, judgmental 
procedures and hunches, writing this knowledge in a logical and 
explicit form, and verifying the correctness ot this wt^treii 
structure with the expert (Texas Instruments Teleconference on 
Expert Systems, 1987). 



The third step of interest to us is that ot knowledge 
structuring, or knowledge representation. This task invclves 
converting the acquired and verified knowledge into a structure 
the computer can use and which is best designed to enable the 
user to employ the resulting computerized system. This step, 
also, is composed of several parts. The knowledge must bt^ 
structured in such a way that the original relationships among 
facts, descriptions, procedures and probability spaces are 
maintained. It must also be structured in such a way that it can 
be used by the inference engine (that part of the expert system 
that makes decisions, inferences, and conducts other reasoning 
exercises). It must be structured in such a way that ^ho tacA Urii 
aspects of the knowledge structure can be stored in a data base, 
and in such a way that efficient and convenient search and 
retrieval strategies can keep the inference engine suppliea wiLii 
whatever data it needs in order to function properly and rapidly; 
and it must be structured in such a way that a user interface can 
be constructed to the expert system enabling the user to easj • y 
ask answerable questions based upon the acquired expert 
knowledge. Many structuring schemes have been developer, cinu 
which one is best to use for any given problem is a factor ot Ihe 
knowledge domain, the type of questions to be aske-i ny uiin u^^er , 
the structure of the inference engine, and the expert languagf^ 
shell to be used. The resemblance of this process to 
instructional design, media selection and other 
knowledge representation aspects to the instructional design 
process will be discussed later in this paper ( Martin and Oxman, 
1988; Waterman, 1986; Benchimol, Levine and Pomerol , 1987; and 
Taylor, 1988). 
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The rest of the design and production process tor expert 
systems is much more closely related to the computer progranunin'j 
profession than to the instructional development protession, and 
so in Figure 1 all steps subsequent to knowledge representation 
have been lumped into one, prototyping, with one exception: 
prototype testing. Prototype testing is another step xn vhe 
process that should sound familiar to the instructional 
developer. It is evaluation, including summative, formntiv- ard 
process, and both obtrusive and non-obtrusive, both normatxve iiia 
criterion-referenced, all thrown into a single pot and stirted 
well. Again, we will discuss this below. 



One other area in which the instructional developer auci \ fi*^ 
designer of expert systems can help each other is in the design 
and testing of the user interface- The user interface is ib^A 
part of the computer system that includes the displays, siiown tc 
the user, determines what inputs and other responses the ur.-^- ^:^ 
allowed to make, and what responses the computer system can 
return to the user. In the case of expert systems, as with yood 
CBI systems, the user interface also includes (and is based upoxi) 
a model of the user. In the case of the exr)ert system, t!ii.\> 
model may be an intelligent system in itself (Systems Group. The 
Open University, 1987). A special language interface Known a 
natural or quasi-natural language, may be employed, ana thit> in 
in itself a kind of artificial intelligence system (Martin a)u3 
Oxman, 1988, p. 226). 



This, then, is the general model of how an expert system is 
designed and produced. It is an overview, and much oi impor i 
has been omitted. But it should be sufficient to show those atea.s 
in which instructional developers can play a part, based upon 
similarity between what they normally do and v?hat musi. be done to 
produce an expert system. Let us now examine some ol Iru--" 
similarities in more detail, beginning with the problem selection 
step . 
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problem: SELECT;:C)H for expert system DEVELvlPMKiST 



The selection of an appropriate problem tor vase in clesig^n -ly 
an expert system is extremely crucial to project success. 
However r this is not easily accomplished. Four issues are 
invoJved: identification of the task to be accomplished, 
identification of the pecple involved in producing the sy^^^^m. 
identification of the final objectives and users, and 
identification of both required and available resources 
(Benchimol, Levine and Pomeral, 1987, p. 162). 



Usually a general type of problem is easily sei'^-ctnd, j' 
terms of either its research value or in terms ot its practical 
value within the organization proposing the project, Ruv. r:ii 
problem must be narrowed and defined, and it must be under si oud 
how the project based upon the problem might pruce^-d. lm- ^^^cj''^' 
to be solved must be examined in detail in order to produce a 
high-level design for the exper^ system that is goitig i-n r.uive 
the problem. The refining of the task and the detinition -^1: ^rw> 
expert system in terms of that task must often occur wittMn r» 
vacutim of knowledge about either the problem or tht? rfM;nn mg 
system. This is analogous to the si uation often facer: In 
instructional development, in which the front-end, job ol tysx 
analysis which, eventually, will lead to some instruction or 
simulator design, must be performed before the device being 
simulated is yet built. Often, for example within the military 
procurement system, the simulator and training system must oe 
designed long before the weapon system it supports has evi»u Imm- • 
prototyped, so that the two systems, weapons and training, will 
reach completion at the same time. The selection ot a problem 
for an expert system project and the conceptualization ot its 
solution often occur within a similar atmosphere. 



One area of critical importance is the selection ni in- 
expert. An expert must be available to provide the knowlonyr^ 
upon which the expert system is to be based, or no expt^rv ^'y^ '. un^ 
can be produced. The first aspect of this probl^nn tM 
determine the level of expertise needed. Not all (in La<*t, moc 
most) expert systems are intended to function on the ler^finng roan 
of a field, performing state- of-the-art work. Most are intended 
to aid or replace workers having a low to ::;\odetate level ol 
expertise, or to help entry-level workers. Some are intended le 
perform routine aspects of a complicated multl- step pro'^ediire. 
or to relieve experts of routine aspects of their work. A 
state-of-the-art level of expertise is not needed lor i h ^ 
of task. Mora expertise is needed on the part of i h?^ t-xp-rt th 
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is intended to be incorporated into the program, hviL a 

world-renown expert is not needed to provide the kMowM>r r 

for advising an entry-level clerk. B'urther, on thor^o iMOj-' t:, 
which top-level expertise is needed, some of the demoijd ^ 'ir^ 

expert's time can be relieved by providing a lower-iev^el — ^per • 
for use during the initial efforts. Thus, the del n nnn i • • 
the type and level of expertise needed is very import.ani . uu • ' 
seems to be no model or theory of how to do this ar. i.U-: -t. 
time. Some work is being done on defining the nature oi - 
expertise and of the expert (Hart, 1986). Mosi. »n i r -it • o,. . : 
development projects involve the identit ication ot the 
subject-matter expertise needed, both in term? or qn<MM • v 
level of expertise represented, as a part of the original v^tn i^.c 



plan. A theoretical foundation for doing this within tnw 
instructional development world has also not been developed, ba^ 
most instructional developers do this intuitively fairly wel ) . 
It should prove to be a fruitful area of theory building ior 
instructional developers . 



The users of the system must be ide^nLified lhi^\ sl.e.^^-. 

and again, instructional developers have a lor.g hi5-.tr 

dealing with this problem, both successfully and uusuccusMiui i y 
as also have evaluation specialists. Who are the real c:M'Mi 
for the products resulting from a project, and are they « r ^-. wm^ 

people who are the clients for the development proc^r;: : i " 

the same people who are paying for the projecl? Aie titny 

represented in the design process? Can the projecu sue • 

they are ignored? Here, again, is an area in whicii b.ii ^ 
instructional development snd knowledge engineering can b->— • 
through the explication of the processes normally used in tn^- 
instructional development and evaluation fields. 



Instructional developers are familiar with the ptoc^-^s ot 
resource identification as a part of the initlaJ planning 
of a project, and the same is true of the knowledge enginoeimg 
project. Before the problem is finally settled upon, it tt->- t 
clearly understood what resources are going to be needed, and 
from where they are to come. Standard resource allocation and 
project scheduling techniques are applicable here, bau • n^^ 
peculiarities of the expert system development vro^y^rv nt- 
kept in mind during their application (Benchimol , Leviric an^i 
Pomeral, p. 164). Moro published case studies oj i hX5. r-: i ^ ^ 
expert system development projects are needed, espic^ -liy u: 
detail great enough to show how standard processes • 
applied, and how they must be modified in order to S(:?:vr^ ' -.r 
expert systems project. 

6 



8 BEST copy AVAILABLE 



DILLS flWD RCMISZOMSKI 



KNOWLEDGE ELTCITATION: HUMAN RELATIONS ASPK-.^^^ 



Knowledge elicitation and knowledge structu;. ir o ( > 
representation are often considered to be one task ny wiit:.'s 
expert systems from the computer world. One reason i ov \ \'\r \ 
that they are often performed by the same people, and -iuoim-. 
that they are usually performed simultaneously. A Thiro r^>ai^Mi 
suspect, is that the typical knowledge engineer knows (ur. imne 
about knowledge representation than about knowledge i-l i t ,xx ^ ui 
at least in a formal or structured sense. 



One characteristic shared in common between the 
instructional developer and the knowledge eugineei is » he nor>d 
conserve the expert's time during knowledge eiicitarion. • "-^ 
least amount of time the knowledge engineer requires ot Ihc 
expert, the cheaper the project cost will be and i h*^. tcK<,t.{»r \.\\ 
project will be completed (Martin and Oxman, 1988. p. 434). 
However, very little knowledge exists concerning how lo inms'iM 
the time required of the expert. The knowledge f-ngint-ej. shoMi 
become generally familiar with the field before apnroaciunu i •} 
expert, through the reading of text books and oLher m<i\.i^r \ r\\ r 
relating to the project. And he trust be a good iisif^-^r qi^i - 
thinker, and a rapid learner. These are also requiteiTieni ^• i '.^^ 
the good instructional developer. However, these are rminrnRi 
requirements for optimization of the expert's liiutr^. Much ivon 
work needs to be performed concerning making optimal usaa^^ 
expert's time. 

The knowledge elicitor must also maintain the t-xpert'- 
interest in the project, make sure he understands \.h'.: r-^?" 
to play, make sure he understands the level of kuowlecKj- w^ir. 
and make sure his good will towards the proved .huH 
knowledge elicitor is maintained. If a failure m any or ^ nt- :; 
things occurs, an accurate diagnosis of the problem i:^ itv 
necessary if the damage is to be repaired. Again, wiltiin ^.n^- 
realm of knowledge engineering these aspects of knr wi ^-^idoj- 
elicitation have not been formalized in any theory, and ^ut^ 
usually dismissed after a short discussion suminriit. i u^t ih-M 
importance to project success and then dismissing them by :a • 
that they call for the knowledge engineer to exhibit qo --^ 
communications and personal relations skills. While linr. ' 
certainly true, it is not enough to be of any spec:iiic! ri<-ip 
conducting a specific project. 

7 
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Several lines of research conducted in insl t uct j fji^a i 
development can be of use in dealing with these probiorrt 
should be extended (both within the instructional deve lt.4'tnt;M i 
field and as applied to the expert system development u« r.-^e: 
Research on client-consultant interactions, initial «neetirr4L . 
appropriate models, and role changes at ditiiert^ui puim:.. <n ^ 
consulting process, have been conducted, aiid some el: torts h .!\/ 
been devoted to teaching students to apply the t i lui > m. l; 
research (Eutt, 1984; Price, 1984; Coscarelli and t. m v.-^* r r , 
1984). Further, preliminary work by Gf^ntry an^i Triuily n • 
formal analysis of communication interfaces i:or instiu ( 
development projects (Gentry and Trimbiy, 1934) o-*:U;'wiv 
applicability here. Work in describing ana prescrio.u?o 
consultant relationship has also been condu('led r 
such as medicine and personnel psychology (i.e.. V^'ni'-n 
Schein, 1978; and TiUes, 1961). And the milii. uy h rj t — 
been sponsoring research concerned with the study ot ei^raiw 
ways in which to utilize SMEs within the inst rud. iona i 
development process. Again, these studies need Lo be (tili^w 
up, and ways in which the knowledge eiicitation prur^--^^ i:; 
similar to and different from the models reseat ch^^^d in tht- ^ i 
studies needs to be explicated. The methudol ugie^ i-'* • 
and appJying this research are already to be found in the 
instructional development literature . 



KNOWLEDGE EL I CI TAT I ON: M2TH0D0L0G I E.S 



The most commonly-discussed aspect ot knowi'-^do^* 
within the knowledge engineering literature is that ouai x:\u 
formal approaches to the elicitation of knowiedov i rc^n i 'i'^ 
expert. Robert Pearson (Pearson, 1988) provides a acuvi ^^v^v^v 
of the most commonly-discussed methods. These are the -um- 
interview, the use of probability estimation, niachiue t aduv. < 
and the Repertory Grid. Other methods discussed iri ( 
literature include the use of historical records, fjhservati^v 
both obtrusive and non- obtrusive, thought experimoj; f n . h «: 
studies (Martin and Oxman,1988, p. 175). 
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The general methods describr^d in Iher.r? .suur':'t-r. at'^ i ' ' 
most part those methods the instructional designr*: • t i - i- 
familiar with and to some extent an expert in. Snmn f^xfM^fM j 
might be the Repertory Grid, machine induction, an^i - i- 

estimation, Pearson also discusses some aspects oi tiie 
structured interview that may not be familiar within 
instructional development . 



The Repertory Grid is a "tool used by psychoiog J Fit to 
represent a person's view of a problem in terms or elemenis .ur 
constructs" (Hart, 1986, p- 174). The grid is r\ l wn-dimeur. j. on 
table of characteristics by cases. The chatactei i-^V ich* att:* 
bipolar, such as strong and weak. The cases are r Ht(.K) on f^-ici 
characteristic on a scale of 1 to 5. Inst ructi on.; j d'vr'lf.:^'; 
have used such matrices in other contexts, such as wii'i (ht- 
semantic differential, attitude measurement, and l^i 
learning theory research. Once such a upitri.^ ha::^. beon uvM/t^i- 
by the expert, it can be analyised £01: pattern..; (/l'ti'T 1 im".:'' 
inspection or through more sophisticated methodt;, v i t 

analysis, cluster analysis, or profile matching (Hcni ^;-r! i 
Hart, 1986). Further, since the world view u! onch t-xj^^ri < 
likely to be different from that of any other expe I . : \. i:- v 
profitable to compare the grids of different expertr. 



Machine induction is a process in which \.he t^mj.HM -j 
generates generalizations when given spor-itic examples (c «'h- 
training sets) as inputs- Special software, callf^d i ;r j. 
algorithms, has been developed to carry out this yroresr . 
Pearson points out (Pearson, 1988), the results ait* <^n\y ^ / 
as the examples chosen for inclusion in i.he Lia.iniuu iw?t 



The development of a probabilistic knowleciof i-j:^» ',;r-M • 
is based upon the assumption that much of an exper t \s Kii.jwiv':-. 
is of a non-exact nature. Thus he is asked the ih/v'* ^ ' 
certainty he attaches to various of his decjsioriy, 
recommendations- These are represented within Lhh- ' • : u/r 
as weights attached to other outputs, and utiempt lo vpi.ni' - ♦ 
expert's judgements in these matters (Peatson, J .» 



To use these methods of knowledyti^ e j .i ci tat i (ni . th'^ 
engineer clearly needs an in-depth understanding uut ' r ' 
particular technique being used, but also ot s tati I i t *^* anu 
mathematics in general. Typically insttuctional ohv^I'm -' =. . 
evaluation experts do not have such an extensive b.^ckQr oim i m; 
quantitative science. However, through an appropr. 1 1 « ? 



9 




DILLS AND ROMISZOWSKI 



re-structuring of our current doctoral programs, iht^y ^ou: i Ij 
provided with such a background. Not only would Ihir - • !• > • 
for performing knowledge elicitation tasks tor (i<.»v»M tm^i' :i 

expert systems, but would allow them to use Ihf* tM^vj- r -w 
engineering methods within more traditional insltut^t lua : l 
development projects. What is not clear hfM t-, ii: v ^^ 
whether a greater increase in quantitative tounda t.i ovis 
would discourage many of our best iustrucliuna i lif v ■ ' ; : 
students from entering our programs. It may be thai tii'_» 
cognitive style and other personality r-lemt-ui.:. l .h.:* ' ^ 

to a career in instructional development are opposed Iv liic^. • 
that would make one an expert in the malhemnl i I • • < 
knowledge engineering. One good way to settle tbj? matl wn 
be to conduct a comparative analysis of appropi: j a t c* M.'rs 
and style elements between populations of instructional 
developers and of knowledge engineers. In any Oci:.e. ctM i - • s 
some instructional developers will be found who Wi. IJ tit two. 
required mold for employing these methods. 



In general, the problem of knowledge elicii^i' ^ ■• 
the knowledge engineer is more difficult than that i ^ i :i • 
typical instructional development project (alih^'M'jM 
there are exceptions to this) (Dills, 198B), 'fhis t;tem::> \ 
fact that the level and type of knowledge that ^ ru^ vvi'-t f 
must model is usually of a much more complex, mur- Uirni;5v: ' 

and a less well defined nature than is the knowjr.'^w- 

represented by a CBI system or a textbook, h qto^l^:M jji-.j:. ' m 
exists between the two types of knowledge when th<^ ^ , . • 
developer is attempting to mold the student's attiLuoe.^, 
represent non-verbal behavior for the student to n^'.-^^l 
teach in interactive process through the shaping ol t^-haviiM 
during interactive practice sessions. It js in im.^ ' j iip; i 
knowledge base for these instructional activities that the 
instructional developer experiences the grenLest chj i ' "/* 
the standard methods for task analysis and content anaJyl•.:^: 

most likely to fail. And these tasks are similar t m*. 

knowledge engineer must face, especially in piojfMn*^ m ut>i 
expert system is to exhibit a high level ot expCLLiL 



KNOWLEDGE ELICITATION: 



OTHER AS-P?;^"]'r: 
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The expert system must not only incorporate tad. upi 
knowledge, but also must represent procedures. coiv:!0)j , 
principles, and standards. But this is only the begiiinw:ci 
expert system must reason in such a way as to narni'-* - i 
along certain dimensions. It must sometimes make jju-^jiv/ 
are only probably true, just as the expert sonn t\v-;» ^ 
must make them as the expert would, in the sense liiai. m : 

uses the same basis in data the expert would a».:: 
that the explanation ' the decision proviued Lo i • i 

explanatory facility v^ee below) is one cou.vi Ifv? ■ h 
acceptable to the expert. Finally, the judgements mari^? L^y fr. 
expert system must have (at least) the same ptc/vvM '': • 
correct as the judgements made by the expert himseli. . 



Further, the expert system usually cont^iuL: i: 
facility- The Explanation Facility tells the u-;cl, v:>^i:'}\^' u 

request, how a particular decision, recommenda^i t^.M - ! 

was reached by the expert system. This includes di i:5p i ay : ti-j 
reasoning pattern used, the data analyzed, and the rui^'i 
utilized. Thus, the expert system must have bui]t im.o n • j 
only sufficient knowledge to duplicate the cxuer i ' ; iv. —. 
(conclusions, recommendations) but must also be abie i dcr-r 

the expert's thought processes and reasoning patt^ 

Oxman, 1988, p. 28). 



There are projects in which only one eyper l ^ i: ' 
may be that the level of expertise required j.;; s\v^ ; : 
expert in the field would do, or that liLtle u i i t-^rr cn^ 
experts are unimportant at the level of the pruje^^'^ " 
also/ that only one expert is available to the pr» y. i 
only one expert exists at the level of expertise rocui. 
Normally, however, more than one, and in some cases icv^ i'. 
experts are utilized. Sometimes the experts art: ^ \ 

utilized, as a team. More often, they are usnd to ucuvi'i- 
expertise about different aspects of the problem . i::" \" 
When they are utilized to different degrees, 5;omet i ir^eii ^m- 
central, or main, expert, and the others ate used to v-: ^ 
knowledge base of the main expert, or to suppiemenx- it. uth-. 
times, the main expert is used only attet the oi her t ; r 
laid an appropriate groundwork, thus conserving the mai (^x^l 
time. In some cases, unfortunately, thr- mdin expcir' ir ; * 
sometime after the project has begun, and other experc- munt. 
utilized to replace him. 
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In all of the multiple-expert situations iislea abuv^ .. » i 
knowledge elicitation problem is complicated by th^' sp-^.m 
problems involved in reconciling and validating Lhc tjxpeiii> vith 
one another. The communications and human t a I i imu; Pi«jlM-au: 
become much more complicated because of the increast-i'd uumi.)er '"»t 
people involved and the greater chance for emotional pi o:>;<MVj^ . f 
develop. One of the best methods currently used in -uch 
situations, by the way, is the Repertory Grid, f -p^^-r: i a j i ■ ; 
coupled with various of the structured interview techniques - 



The knowledge base in the phxlusophy of sciences, i 
psychology of the human world-view, and the nature of th^^ 
scientific method that many instructional developer and 
evaluation experts possess, is typically not found -r\oj'.-j 
professional knowledge engineers- The inst ruct j om^ ^' ' : : 
can make use of this knowledge in trying \.o r-srabl i-'h » ? 
reasoning patterns and paradigmatic aspects or t hp 
understanding. This should enable the im^Lructioiui i 'i..!v ii'^ ^ 
more quickly model the more fundamental aspects of t/ir^ i.w,,,,, 
than would someone lacking this background (set^?, tar. examp:^', 
Davies, 1984; Stahl , 1984). The use of a melhod-u o^j y yn- 
generation of methodologies, such as that deveioperj by Hui-MuriL 
and his associates (Hutchinson, 1984) for Ih^- put^^ ' 
formalizing the use of this fuundational knowledy- in r he 
development of new methods fot eliciting the deep : uc. Lkj • ^ 
the expert's world-view concerning the ptobiem ai hand f^h^ju'u 
prove fruitful not only to know. edge engineering and 
instructional development, but also to cognitive psyc:hojc»uy ^ud 
the philosophy of science. 



Software for use in knowledge acquisition is bemo 
developed. One type of software, just beginuir'n .o 
is the Knowledge Acquisition Facility. This is a part r:^ r .^ 
software that carries on a dialogue with Ih-- ; r. . r»M- ' - 

knowledge and procedures from him, and directiy in^v.-Mp/j- ' ''i- 

into the data base. Such a system may be speci.'*';' " v^: 

the system b(=iing constructed, or may operate throuuh ^ ^^^^ : ■ - ? 

interface. The same system may be utilized later io uf,-! 

expand the expert system as new knowledge is anquir^^i -^w^- -i- 
knowledge becomes outdated (Martin and Oxman, i^--^;. 



A second type of software of use to the kno.'; irj^ 
elicitation process that tracks pieces of kno^'J - . r,.., ^ 
computer system and other developmental prccessei: as vri • , 
identifies inconsistencies within the databair-!. .xr. / • 
redundancies. One such system, called TRACE, is cut^fMiriy 
development at Intel liSys, an expert system ueve L dumk^^-^ m^.. 
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New methods for eliciting knowledge are bauiy n t^edt-M rm.- i; 
knowledge engineering. Current methods ate tiinf- ruf i n; }.! j 
costly, and are not guaranteed to properly elicit t'rjo i\<-A2<i^^(\ 
knowledge without the intuitive intervention oi pvvw- ; ■ . --^ 
knowledge elicitor. As in instrucuionai developipent {pti :^ 
Bass, 1984), much of the knowledge elicitatjon •t^r.cl t'i;: 
knowledge engineering is currently an art £onn, not ci ' o-nv'^ ; 
and so cannot be automated. Pet haps this will always : • ■ !• 
case, but at least it should be possible to deveiop bctti>r 
techniques to use when performing the art. I nt:5 v r ncM i m: r i 
developers are in a good position to develop sonu- ^jf i he, . . ^ 

would certainly benefit in turn from aay such n-w t f. - 

might be developed. 



KNOWLEDGE REPRESENTATION 



Knowledge in an expeit system is structuren. j^r'Mx- 
in two parts, which are built and stored sepatat*-iy \'.yJ • 
are designed to interact with each othei Otie i^^i^ r i . i 
inference engine, and contains the knowledge emeriti i\::\t ( h • 
to reason. The other part is called the knuv/ltvi.j^ 
contains the facts, rules and other types o£ knuwiedy" u — : 
the inference engine in reasoning. 

The knowledge engineer must decide what sLnucture I?; ur.^e :i 
arranging and organizing this information ao tha- n .^ i 
accessed and utilized by the computer, and ultimately by i.^- 
user, in the most efficient and effective manner. T\'o 'j j* • • 
must be answered. The first is how the infer^^nce engine 
function. The second is how the knowledge- i.s i c i - . 

within the knowledge base- 



Both of these questions must be ausweteu ::i t < 
logic of the field in question, and also i-i Vf-^rn:-' < = 
structures available within the compuLer . 




Several structures for representing kno\^^^v^itJ< ' 
knowledge base have been developed, and are usuiily o 
terms of how various aspects ot the expert's kucvle-- 
each other. Special languages have been deveJop^u I o 
the implementation of these stractute:^, <ind tlM .-^- 
be used in any significantly large project. They 
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cost for constructing the expert system, b\it lir.^y u 
own restrictions and limitations to the resulting 
Therefore, one decision that must be made is whici-. : i-:": .v- 
be used to structure the knowledge. This decisiLM 'mu - 
simul tanoously with the decision concerning wiiJci! irjit-j 
structure to use in representing the knovic^aoc 
1985, Chapters 3, 7 and 8; Martin and Oxman, 1^6^;. 



The instructional developer is not 1 ike i y t r?- ■ 
with the ways in which knowledge can be structutcu w: ' i ^ 
knowledge base. However, he does perform ta^^Hi.; .m - - 
functionally similar. He structures the flow of into;r-.jt).. 
within lesson designs when producing CBI. It h,' ivi rr— ^ " ; 
the CBI lesson, he structures the knowledge even mort^ car^^^: 
In doing this, he undoubtedly tries to djsco\/r^r ■ - i: 

natural structure to the subject matter heing laughi. , u:. 
this structure in designing his lessons. He aKsu .i . -i-; * ■ 
structure the information according to design heu j .is 1 1 ''-^^ v.' 
according to what is known concerning the psynlioj': v , ' 
In designing a CBI or textbook page, he attempts Lo n:?-^- i'^- 
the research on text design, and is therelure arp^y >V ' - 

logical structure to the information. In doing tii^jL^^* t i^! ij' 
instructional developer is restricted oy the Chj ni' rj-r ; - 
language, the subject-matter structure, and the rjef^d.s cind 
abilities of the user, much as is the knowledge '::rj^iu'^>t . 



Four knowledge r epr eseiatation schemes dominrne t.he i'.n^^W! 
engineering field, and the instructional develup-v ■ : 
familiar with these if he is to work with expert by:.;wMn 7; 
are rules, frames, semantic networks and f i i s t-ui dti. 1'^ 
Others are being developed, and eventually may suuui.irr ' -m > 
One should be aware of these new development.?^, bul - «: • 

almost all work is performed using one or mote oi i i e' ^' 1 - • • 
methods (Martin and Oxman, 1988). 



Rules are the most commonly-used form. Know U-dge is 
represented as a series of logical IF-THEN s ta t f^-mein nrus i 
inference engine calls these rules in a sequenci^ neLermiu'O 
the subject matter, determines if the I ' statem<^Mil. has Ij^-m; 
fulfilled, and if so, carries out the THEN statement . The THh'N 
statement may be to take an action outsicie trie •.HMui- . ' 

print out a decision, or to change an internal Vciri.inhv ^'vn: v. 
establish the numerical value of a variable in ai , i : 
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Frames and semantic networks are similar, and ut/ir' i 
upon groupings. Semantic networks consist of i:erir 
connected by lines. When drawn, a diagram i t-pr esf.^nt : ^ • 
semantic network looks much like a tlow chart io: 
instructional development project, or a PERT criarl. 
represent concepts, and the connecting lines i = 
relationships . There is a 'hi er arc hi a I t ^jx cM.i on:ia). p 
concepts, such that concepts lower in the diagram 
characteristics of concepts higher in the struct^ur>t , l:. - 

of umbrella arrangement exists. If "ship*' is a hio ' 

concept, and it is a characteristic defined inro th^.^ •'^y-v — 
"ships" have "hulls", then, if "aircraft carrier" • :^ - 
lower-level concept, and is connected to the curicet'L 
the "is-one" relationship, the inference enoine. ! i 
automatically infer that "aircraft carriers" h^;vc "ip-i 
(Waterman, 1986) . 



Frames are similar to semantic networks. TL tiie n^Mic;: ar^ 
considered frames, then the frames indicate r- lciu (m-. i.-^ vi i*-^ 
frames. Each frame is a container, and the lanes m the ciiauran^ 
connect the frames, and indicaLe f rame- to-f r ami* r a t. mjiv v.- 
The frame itself can be considered a concept. Tha u(\.ir;:u.M ' "-n 
puts facts, procedures, concept names, desiyh ; n i ^ . . .. , 

name of the expert who uses the concept) into Ihe Itaiuc, T^ j.. 

information is stored in slots. Each Iram^ has a r:<M.^ m 

of slots, or pigeonholes, and each piece of. iiiLoi i. ; m:: 
or more slots. 



Thus each frame is a cluster of related .?':ri 

cluster itself relates the facts I'o other ciu: i ' • . 

may or may not have an umbrella relationship riy. «ieSr: jbf^M 
for semantic nets (Benchimol, Levine and Pomeroj , l^b: ' 



ERIC 



Declarative knowledge can be represented by vai • 
logical structures. Commonly used are proposi t icna i 
predicate calculus, and first-order predicate tjaleuiu 
Statements such as "Lassie is a dog" and Ld:.^'^^- 
then Lassie is a mammal" would result in the inlet one 
deciding that "Lassie is a mammal" in these sy^tr-n-;. 
concerning these types of representation*;. r.^n t'C ;ear 
Martin and Oxman, chapter 10, or Benchimol, Levj^M- i ■ 
chapters 3,4 and 5. 
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Again, most instructional developers do not iicivt; .j : -i 
background in symbolic logic, and so will havf^ trtM.: ] ■ 
schemes. However, this situation could easily be v^^iwiiiy: 
short course in the instructional development dep^: r i.i::^- • 
summer institute if enough devel opers wanted to woik wwh -yijf: 
systems. And these schemes are easily learne^i, i\n ;: ^v-m>: — - 
learn them on their own. It one is to serve as a I. tont-^'Tu; 
expert on an expert system project, one n\ust b-.' 'inv- ■ n - 

these schemes -through one. way or_ another 



One of the areas in which developf?r5> "a-i c^. ■ ^.i » ^ 

system field is to develop ways in which tne in^.KLUii - 
of a field can be easily and quickly del-e-L id lu^-'.: ' 
information can be used in determining how the knovi-(i'j^- • . 
represented. Again, the structure of the tieid c?^n [ rr- ■ : 
always be deduced from information concerning th^-: p^j. r ■ « 
and other world-view features of the expert's kncvicMit;*- 
structure. As argued earlier, a Lormali'/t^d met^uwi f (m 
determining the paradigm of the expert and oi vr-iM- i . 
into a knowledge structure could be developed, aii«; wt3u; > 
useful. Further, most knowledge engineers have r.i^ i^it - r 
this area, and many evaluators and instructional (it»- ^ i "v 

The structure of the inference engine mu.sl cn::v r » 
determined, and several structures (in this c dSf-. pr cjc-MiuM^ 
reaching a decision) are in common use, Oli.eu a tf*pny~:i.> :r 
inference engine is purchased, rather than cuii toin-iua'ir; , ri-r 
again, its workings must be understood Ir an .uppror^ri^?- -'.m 
is to be made. Some of the most con^Bou i ater s-.-k -p'- 
(Martin and Oxman, 1988, p. 64): 



These methods of inference will not be- d^-i m i h'^ i r-^i 
they are fully discussed in the references. But tht:? 
instructional developer must be familiar with ^^^^ ^ • '^•^ 

that the proper inference technique can be niatch^t:^ • 

at hand, and the knowledge base can be r epr c-sen t^»'.' 

properly fit the inference engine. The knowledy^.- 

be familiar with the ways of building an mlc^re;- . 
knowledge base, since the way the knowledge is '-Iruci-i^-i 
used must be decided as the knowledge is being .ir . ^ 



-backward chaining 
-forward chaining 



-breadth- first search 
-depth- first search 
-heuristic search 



-pt i-ihloTTi r<^!auct lor 
-pat t er » ^' ^' h ■> 



-•-*ven t ~dr i v^*r ^ -^r 
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Typically an expert system is being pLototyped as rhe k i' ^ 
structure is being developed, and early cit^c^i^.i^ns r^^f- h 
necessary and critical to future expansions. Tims, i }m> 
instructional developer, if he is to uti]i?'>e ull; kr ",- m .ir^'r> 
front-end analysis in knowledge acquisition for exuujrl 
development, must become knowledgeable coacernjiiu new • 
knowledge is to be structured and utilized by ihe compmif'L 
system. 



Thus the instructional developer Is tcqiiit:?-d :M-v-i 
knowledge of inference engines and knowledge repr^s^-i^<: • 
schemes, and this requires that he develop a knuwlt^d-j 
and of various inference schemes. Tt doeis iiol r^q :* 
become a computer programmer or a systems etigiiK^er P 
require that he become familiar with the Janyuagc^s lyi.' - 
in expert system work, but on a conceptual I travel . In r " 
projects, the programming will be periorined by - 
the developer must communicate with this .spt-ciaijrt n ^ 
know the restrictions and advantagei- placed uuui; *' - , 
language being used. 



TESTING 



Not only must the resulting computer progrn^T^r- nc \ • 

the resulting knowledge structure and interenoe pav, tni n-^ mu:^ 
also be tested. Further, the usefulness ot the rp-'nii i^r^i j 
to users, and the need for updated knowledge, must be «-v<i i uat eri . 
These things must not only happen when the syst --n^ hr^^ 
prototyped, but at each step in its evolution, an«:i ^ ^ r ^ i i , 

after it has been completed and turned ovr^r io t h'^ ^^'Jr 

is clear that instructional developers poss:ess pyp^^riis- or- 
value here, especially in designing and oou'iuci u-.g u^;cr 
interviews, evaluating aging knowledge basos. -jn-i ^.^r * i \ • 
system-made decisions against the real world. 
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USER INTERFACES 



Instructional developers possess kuowicdg- -.j m i 
two fields that are related to the desigr^ oE 1 rM- i^^t^-^ 
of expert systems. The first concerns sci i!tv ' r 
factors work. The design of the interface for uhf! u<^'-t ij 
to the design of an interface for a CEl i^j^i^ltrtui, ■: 
involves a great deal of screen and text desigri coii.s « r ' 
Further, the functional design of the interface vm ' 1 « ■ 
what the user can ask the system, the type and in.MMiCj. mi wm 
gives the system data, and the type of reply he ca?j n.-^ - 
Instructional developers already have sl.rinurtLd vfrj^y 
discovering the appropriate forms for such intt:r acl.j c)m> 
of the user's intentions. 



A second area in which instructional deveiupers '^-jn ?: 
contribution to the interface design is thtuuyi' i?:-rc '-mv'. 
of cognitive styles. It is known that not all i-yy.i-"^.' ^' r ' !:. ' 
the same manner, and that, further, experts and ^.m-'^m. 
field think differently. The expert system muiii. ^r .-- m 

expert does, at least in high-level expert sysl.*-nis. r 

user were an expert himself, and reasoned as t.h?? '-yp^M 
probably would not be using the system at all. TIjip » • ^ 
always true, of course, but often il is. Th^jr^Morc^ v-; < 
novice or the other user receives an answer i' o ' 
asks the Explanation Facility to explain how thr? anrw^: 
reached, it would be useful if this answot rjonjo d- r_ ■ — f 
terms of how the real expert would arrive this rMi.^iv^v 
(supposedly, this is also the way the compul cm Hrniv.'' 
answer), and also in terms of how this answer couid ri! - 
following the reasoning style of the user. In other vm-.w.. , 
the expert is a "reasoner by comparisons**, and arrived • 
answer by comparing various factors, this solution woij ^ ^ 
explained. The computer could translate this into the 
style, which might be "reasoning by contrasts" r and ^ • 

chain of inference to the user also, oncf> i i. ionrnt-d v^/h n - 
style was. 



Currently, no such system exists, but by mou^^ljirj - ii" 
student or other user, such a system could be dt^^^'^i-r • * 
attached to almost any independent 1 y-devel t^pini Mxpf?r t v ! v 
Such a system would be particularly usef ul in tr n ■ i: -m.. 
reason according to different slyles, or in uiutig expi-t i y 
as instructional delivery devices, Inst ruct i oi i • - 
in prime positions to design such a st udenL modf • j / 1 / w 1 ' • 
provider . 

BEST COPY AVAILABLF 
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SUMMARY 



It is argued that ins tract iona 1 de\/f-\i opet <i r e 
excellent position to make contributions In I ( 
systems development, particula\iy in the rj:^as r, .. 

acquisition, knowledge structuring, testing, and de^J'o^ 
interfaces . 



They must become familiar with the iooii., sys^tf^'^>'* 
approaches used in the field by knowledge enghuM>, • i 
to make this contribution. 



Once they have learned the fundamentals ui t.ru^ { 
can apply their specialized knowledge and Hxp*^r < ^ufM^ 
practitioners and as researchers. In doing i.ht y ^ 

a new technology to educational use, as wei 1 as [i-.vw^f 
knowledge engineer with new tools that he will I'nxd 
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